Computing systems are extremely prevalent today. They include a plethora of hardware and software components that originate from a wide variety of manufacturers. The need for efficient and consistent collaboration between these various components is essential to the success and usefulness of these computing systems. An operating system of a computing system provides the interface between user application programs and the underlying hardware or software components of the system.
Computer operating systems commonly incorporate features to communicate system and application information, to and from a variety of devices. These features are generally provided by multiple manufacturers. The growth of the computer industry has engendered a large number of companies to provide both hardware and software peripheral products for the market. In all of these cases, the operating system manufacturer has to ensure the compatibility and the exchange of data within and between the computer environment and any such hardware or software product. To ensure that the multitude of application programs that are executed on a computer system are able to effectively communicate with peripheral devices the operating system designers have developed interfaces that allow device-independent access. Two such interfaces are a device driver toolkit and Windows Imaging Acquisition (WIA) service.
Communications between the operating system and individual manufactures components are usually facilitated by customized software programs that function as a translator and are typically referred to as drivers. A driver provides an interface between proprietary manufacturer components and the operating system. The device driver toolkit provides Application Program Interfaces (API) and other tools needed by developers to write drivers for the operating system environment.
WIA service serves a similar purpose but includes a number of enhancements and features, the details of which are beyond the scope of this discussion. Suffice to say that WIA provides standard means for drivers and system components to provide device status and transfer error recovery user interface during data transfers to applications that support WIA.
The constant evolution of the computing industry and the advancement in technology results in changes to operating environments, operating systems, hardware devices and software components. The nature of these changes often necessitates a corresponding change or more appropriately an upgrade to the associated drivers that provide the interface between the new and the legacy technologies.
Drivers are typically designed and written by the operating system's manufacturer as well as by independent vendors and other third parties. By way of example only, an operating system such as the WINDOWS brand operating system from Microsoft in Redmond, Wash. includes a number of device drivers when sold. However, the vast majority of these drivers are actually released after the release of the operating system. In other words, the version of the driver that ships with the operating system is probably not the most recent version. Vendor fixes of defects are also delivered to end users, in the form of patches. In addition, new hardware products that are added to the client computing system require drivers to be installed. There are numerous drivers to support the vast array of available hardware products. For example, for one particular model of a hardware device such as a network interface card (NIC), the manufacturer could have various versions of the driver, each version directed to address different combinations of the NIC and the operating system. The same model of NIC could also have drivers that were developed by other third party vendors. In other words, there are multiple drivers and multiple sources for drivers that confront a user. Similarly, there are a vast number or application programs that are executed in computing environments. These application programs generally communicate to the various peripheral devices, using any one of the vast number of device drivers. As with all things, there are situations in which an error occurs on a device during one of such communications. A method for addressing these situations in a consistent manner across the variety of drivers and applications is needed.
Traditionally, the occurrence of an error results in the error condition being handled by the device driver and sometimes reported to the application program. When the error conditions are handled by the driver, the user experience becomes very device or manufacturer specific. The reporting of an error to the application program takes on many forms that can be driver and/or application specific. Applications need to be able to appropriately receive and respond to a wide variety of possible driver reactions to error conditions. In some instances, a Boolean value is provided to indicate that bad result data is being passed. In other instances, the application program simply receives no data and must then conclude that an error has occurred. In some rare circumstances, an error code or the like is transmitted to the application program, such as in the WIA paradigm. In either case the application program's response to the error condition generally results in a termination of the communication session. As can be appreciated, some error conditions are created by simple circumstances that can be easily rectified by the end user e.g., the document feeder in a scanner can become jammed. However, traditional systems provide no way of indicating, and having a user resolve, a fixable device error. Instead, the driver fails and the application has no way of determining the nature of the problem. As such, the application generally terminates communication and any data acquisition that was ongoing at the time of the error must be restarted from scratch. For example, while scanning twenty documents, if a paper jam failure occurs at document eleven, regardless of the fact that it is a fixable error, the user is required to start all over with document one.
Consequently, what is needed is a system and process for monitoring events that occur during communications between a peripheral device and application programs, in the operating environment. Further, such a system and process should report device status and problems, provide error recovery and only abort the process after giving a user the opportunity to first correct the problem. Even further, such a solution should be compatible with legacy applications and device drivers. Further still, an improved user experience is desirable. A user should be able to obtain meaningful information about error conditions and possibly rectify those errors without having to necessarily re-start any data acquisition process. All of these functions should be possible even when the error reporting user interface is not solely controlled by the device driver. Finally, this system and process should reduce user frustration and increase consistency in the handling of device errors.